Adding initial draft of the Containerz yang model by alshabib · Pull Request #1389 · openconfig/public

alshabib · 2025-11-09T16:50:58Z

Change Scope

This is a yang model for the gNOI.Containerz service.

This change is backwards compatible.

earies · 2025-11-10T20:22:21Z

release/models/containerz/openconfig-containerz.yang

+
+  augment "/oc-sys:system/oc-sys-grpc:grpc-servers/oc-sys-grpc:grpc-server/" +
+          "oc-sys-grpc:state" {
+    when "../config[contains(services, 'oc-containerz:CONTAINERZ')]/enable = 'true'";


This identity does not exist. For new gRPC services, there is current way and potential future for expansion but you'll want to at a min follow what you should see for P4RT and GRIBI

earies · 2025-11-10T20:24:26Z

release/models/containerz/openconfig-containerz.yang

+      "A collection of counters that were collected while evaluating
+      access to the gRPC server.";
+
+    container counters {


This appears to try to add an overlapping container under /system/grpc-servers/grpc-server/state. Suggest consideration of bucketizing "containerz" specific state/counters under it's own hierarchy specific to this set of services

@alshabib see:

/system/grpc-servers/grpc-server/connections/connection/state/counters

earies · 2025-11-10T20:24:51Z

release/models/containerz/openconfig-containerz.yang

+      "A collection of counters that were collected by the gRPC during
+      the authentication process.";
+
+      leaf connection-rejects {


What are these connection-* related leafs meant to convey or were they copied from other model?

They seem to be a duplicate of the counters in /system/grpc-servers/grpc-server/connections/connection/state/counters. I think they are not needed because they are already present.

/system/grpc-servers/grpc-server/containerz/state/counters could be created if there are containerz specific counters. But all generic "grpc-servers" counters regarding client connections should appear in:
/system/grpc-servers/grpc-server/connections/connection/state/counters

earies · 2025-11-10T20:26:41Z

release/models/containerz/openconfig-containerz.yang

+    description
+      "gRPC server containerz freshness-related data.";
+
+    container containers {


Similar suggestion as above - consider grouping under containerz hierarchy first. If this is meant to be similar to docker ps outputs then can align as such. Any counters should go under child counters container at relevant hierarchy.

robshakir · 2025-11-10T21:39:44Z

release/models/containerz/openconfig-containerz.yang

+
+  augment "/oc-sys:system/oc-sys-grpc:grpc-servers/oc-sys-grpc:grpc-server/" +
+          "oc-sys-grpc:state" {
+    when "../config[contains(services, 'oc-containerz:CONTAINERZ')]/enable = 'true'";


We don't allow for this kind of when statement using contains AFAIK.

This concept was introduced in the gNSI related models

https://github.com/openconfig/public/blob/master/release/models/gnsi/openconfig-gnsi-authz.yang#L205

But this identity does not exist and each gRPC service domain should really bring in a distinct related container and group everything related underneath (commented above)

robshakir · 2025-11-10T21:41:16Z

release/models/containerz/openconfig-containerz.yang

+      "gRPC server containerz freshness-related data.";
+
+    container containers {
+      list container {


I see this as duplicative to the ListContainer RPC, which is fine in principle, but how do we expect the two to be used? I presume the thinking here is that some clients will just subscribe through gNMI to understand this state?

robshakir · 2025-11-10T21:41:37Z

release/models/containerz/openconfig-containerz.yang

+        "A timestamp of the last time a gRPC client succeeded
+        in establishing a connection to the server.";
+      }
+      leaf running-containers {


Is this a useful metric if we also have the list of containers?

dplore · 2025-11-12T00:13:15Z

/gcbrun

OpenConfigBot · 2025-11-12T00:15:24Z

No major YANG version changes in commit 6d0ec50

dplore · 2025-11-12T00:18:38Z

release/models/containerz/openconfig-containerz.yang

+      "A collection of counters that were collected by the gRPC during
+      the authentication process.";
+
+      leaf connection-rejects {


They seem to be a duplicate of the counters in /system/grpc-servers/grpc-server/connections/connection/state/counters. I think they are not needed because they are already present.

/system/grpc-servers/grpc-server/containerz/state/counters could be created if there are containerz specific counters. But all generic "grpc-servers" counters regarding client connections should appear in:
/system/grpc-servers/grpc-server/connections/connection/state/counters

dplore · 2025-11-12T00:18:41Z

release/models/containerz/openconfig-containerz.yang

+      "A collection of counters that were collected while evaluating
+      access to the gRPC server.";
+
+    container counters {


@alshabib see:

/system/grpc-servers/grpc-server/connections/connection/state/counters

dplore · 2025-11-12T00:21:10Z

release/models/containerz/openconfig-containerz.yang

+      list container {
+        key "name";
+
+        leaf name {


For openconfig style compliance, this needs to be a leafref to a leaf of the same name in a "state container"

for example:

public/release/models/system/openconfig-system-grpc.yang

Lines 75 to 129 in 1463f23

list grpc-server {

key "name";

description

"The list of gRPC servers that are running on the device. Each

instance within this list corresponds to an individual gRPC listener

that listens on a single TCP port on the specified addresses.

Where there are multiple services that run on a single port, these

are enabled through the service leaf-list which uses the GRPC_SERVICE

identity to list the supported service types.";

leaf name {

type leafref {

path "../config/name";

}

description

"Reference to the name of the service that is to be enabled.";

}

container config {

description

"Configuration parameters relating to the gRPC service.";

uses grpc-server-config;

}

container state {

config false;

description

"Operational state relating to the gRPC service.";

uses grpc-server-config;

}

uses connections-top;

}

}

}

grouping grpc-server-config {

description

"Configuration parameters corresponding to an individual gRPC

server.";

leaf name {

type string;

default "DEFAULT";

description

"The name of the gRPC server instance that is running on

the local system.

If the operator does not designate a name for the protocol

instance (e.g. config), the implementation should use the

name of 'DEFAULT' (e.g. state). In addition, for

implementations that support a single gRPC server instance,

the default value is recommended for consistency.";

}

dplore · 2025-11-12T00:24:13Z

release/models/containerz/openconfig-containerz.yang

+    description
+      "gRPC server containerz freshness-related data.";
+
+    container containers {


Consider the same fields from a docker ps (or docker ls if the intent is only to show running containers)?

brianneville · 2025-11-20T15:04:02Z

release/models/containerz/openconfig-containerz.yang

+
+  // Augments section.
+
+  augment "/oc-sys:system/oc-sys-grpc:grpc-servers/oc-sys-grpc:grpc-server/" +


I'm not sure if we really should be augmenting the grpc-servers list with information about something which is system-level (i.e. containers are not tied to a particular gRPC server in any way).
maybe something like /system/containers would be more appropriate?

(likewise for the augment below)

dplore · 2025-12-02T17:36:59Z

FYI: set project review status to "waiting for author".

alshabib requested a review from a team as a code owner November 9, 2025 16:50

github-project-automation bot added this to OC Operator Review Nov 9, 2025

alshabib force-pushed the containerz branch 2 times, most recently from 3ea4065 to 3f56831 Compare November 9, 2025 16:53

Adding initial draft of the Containerz yang model

6d0ec50

alshabib force-pushed the containerz branch from 3f56831 to 6d0ec50 Compare November 9, 2025 16:56

earies reviewed Nov 10, 2025

View reviewed changes

robshakir reviewed Nov 10, 2025

View reviewed changes

OpenConfigBot added the non-breaking label Nov 12, 2025

dplore reviewed Nov 12, 2025

View reviewed changes

brianneville reviewed Nov 20, 2025

View reviewed changes

dplore self-assigned this Nov 21, 2025

dplore moved this to Ready to discuss in OC Operator Review Dec 2, 2025

dplore moved this from Ready to discuss to Waiting for author in OC Operator Review Dec 2, 2025

	list grpc-server {
	key "name";

	description
	"The list of gRPC servers that are running on the device. Each
	instance within this list corresponds to an individual gRPC listener
	that listens on a single TCP port on the specified addresses.
	Where there are multiple services that run on a single port, these
	are enabled through the service leaf-list which uses the GRPC_SERVICE
	identity to list the supported service types.";

	leaf name {
	type leafref {
	path "../config/name";
	}
	description
	"Reference to the name of the service that is to be enabled.";
	}

	container config {
	description
	"Configuration parameters relating to the gRPC service.";

	uses grpc-server-config;
	}

	container state {
	config false;
	description
	"Operational state relating to the gRPC service.";
	uses grpc-server-config;
	}
	uses connections-top;
	}
	}
	}

	grouping grpc-server-config {
	description
	"Configuration parameters corresponding to an individual gRPC
	server.";

	leaf name {
	type string;
	default "DEFAULT";
	description
	"The name of the gRPC server instance that is running on
	the local system.

	If the operator does not designate a name for the protocol
	instance (e.g. config), the implementation should use the
	name of 'DEFAULT' (e.g. state). In addition, for
	implementations that support a single gRPC server instance,
	the default value is recommended for consistency.";
	}


		// Augments section.

		augment "/oc-sys:system/oc-sys-grpc:grpc-servers/oc-sys-grpc:grpc-server/" +

Conversation

alshabib commented Nov 9, 2025

Change Scope

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dplore commented Nov 12, 2025

Uh oh!

OpenConfigBot commented Nov 12, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dplore commented Dec 2, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants